Communication middleware resides between client and server applications in distributed systems. Middleware simplifies application development by providing a uniform view of networks, protocols, and operating system layers. Object Request Brokers (ORBs), such as Common Object Request Broker Architecture (CORBA), DCOM, and Java RMI, eliminate many of the tedious, error-prone, and non-portable aspects of developing and maintaining applications programmed using mechanisms like sockets. In particular, ORBs automate common network programming tasks, such as object location, object activation, parameter (de)marshalling, socket and request demultiplexing, fault recovery, and security.
The United States Department of Defense has mandated compliance to the Joint Tactical Radio System (JTRS) Software Computer Architecture (SCA) for all new communication radios that operate between 2 MHz and 2000 MHz. The SCA further requires software applications to run under an operating system and that data be passed using CORBA middleware. CORBA (Common Object Request Broker Architecture) provides platform-independent programming interfaces and models for portable distributed-oriented computing applications.
Conventional CORBA implementations have limitations that make it hard for them to support performance-sensitive applications effectively. For example, conventional ORBs like CORBA support a limited number of statically configured protocols, often just GIOP (General Inter-ORB Protocol)/IIOP (Internet Inter-ORB Protocol) over TCP/IP. Further, conventional ORBs do not allow applications to configure key protocol policies and properties, such as peak virtual circuit bandwidth or cell pacing rate. Moreover, conventional ORBs do not support simultaneous use of multiple inter-ORB messaging or transport protocols. Yet further, conventional ORBs have limited or no support for specifying and enforcing real-time protocol requirements across a backplane, network, or Internet end-to-end.
Another significant disadvantage of commercial middleware, such as CORBA, and operating systems available today is they are much too slow to allow use in power-constrained applications, such as the Objective Force Warrior, munitions and Unattended Ground Sensors (JTRS Cluster “5”). By adding sufficient processing power to overcome the latency caused by the operating system and middleware, the resulting heat and battery life reductions make compliance with JTRS SCA requirements virtually impossible. For non-battery powered applications, such as JTRS Cluster 1, there is a tremendous recurring cost and heat burden that the program cannot reach. A large pat of the performance demand is required performance because of the excessive heat dissipated by numerous 1000 MIP processors.
One attempt to resolve some of the limitations of middleware, such as CORBA is implementing a pluggable protocol framework. A pluggable protocol framework refers to using customized ORB interfaces that allow data to be passed without going through the operating system. The pluggable protocols are software applications designed using a standard protocol configuration to allow custom messaging and transport protocols to be configured flexibly. Nevertheless, software pluggable protocols are similar in speed to the middleware application and they may not be portable across platforms.
Thus, there is a need to improve the speed by which data is communicated in a communication system by avoiding software applications, such as the operating system and middleware. Further, there is a need to improve latency in SCA compliant software solutions such that more efficient processors can be used. Even further, there is a need for a joint tactical radio system (JTRS) software computer architecture (SCA) co-processor that implements essential services to a waveform application.